| Просим разъяснить, каким образом будут осуществляться запросы через сервисы налогового мониторинга в адрес российского юридического лица: с ИНН/КПП (InnNm/KppNmForeign) или же только с ИНН (т.к. согласно описанию к формату (КПП KppNmForeign) обязателен к заполнению только в случае, если участник налогового мониторинга - иностранная организация). |
| КПП участника налогового мониторинга. Обязателен к заполнению в случае, если участник налогового мониторинга – иностранная организация |
|
Максимальный срок ответа на требование? 1. Для расчета плановой даты предоставления ответа на истребование (Сценарий №3 «Файловый обмен» или 12 «Истребование документов») ориентируемся на атрибуты • Дата формирования документа (Требования) • Количество рабочих дней на исполнение требования после получения. Принимает числовое значение. В настоящий момент возможные значения: 5 или 10. 2. При поступлении Документов в электронной форме и отсутствии оснований для отказа в их приеме получатели не позднее трех рабочих дней со дня направления Документов формируют Протокол обработки 3. При этом датой получения считается не дата формирования Требования, а дата поступления, зафиксированная в Протоколе обработки полученного Требования (атрибут «Дата поступления документа»). 4. Таким образом, максимальное время обработки Требования Налогоплательщиком составляет 3+5 или 3+10 рабочих дней от даты формирования Требования, в зависимости от атрибута «Количество рабочих дней на исполнение» |
| Срок ответа на требование о представлении документов (информации), пояснений составляет 5 (10) дней от даты поступления такого требования, зафиксированной в протоколе обработки. |
|
Просим разъяснить правила присвоения значения элементу IsContentAvailable. По ранее данным разъяснениям, данный элемент имеет признак обязательности и необходим для того, чтобы налоговый инспектор понимал, какой из сервисов в случае необходимости должен быть вызван: "Запрос на просмотр документов" (Сервис №5) или "Запрос на доразмещение документов" (Сервис №6). Если документ является электронным, состоящим из двух xml-файлов ("титул поставщика" и "титул покупателя"), то есть если, документ является многотитульным (например, УПД), какое значение нужно присвоить элементу IsContentAvailable в следующих ситуациях: - в электронном архиве есть xml-файлы электронного документа, но нет pdf-файла визуализации; - в электронном архиве есть pdf-файл визуализации, но нет xml-файлов электронного документа. |
|
Значение элемента IsContentAvailable: - в электронном архиве есть xml-файлы электронного документа, но нет pdf-файла визуализации = 0; - в электронном архиве есть pdf-файл визуализации, но нет xml-файлов электронного документа = 1. |
|
Если в запросе по сервису 12 будет присутствовать элемент "DocumentId" в составе элемента "RequestedDoc", допустимо ли в запросе по сервису 16 заполнить два составных элемента ResponseInfo, в каждом из которых указать один и тот же DocumentId, который был получен в запросе по сервису 12? Иными словами, если НО в запросе укажет "DocumentId" электронного документа, который содержит два xml-файла ("титул поставщика" и "титул покупателя"), то есть если, документ является многотитульным (например, УПД), справедливо ли будет заполнить два составных элемента ResponseInfo, продублировав в каждом одинаковые: "Номер документа", "Дата документа", "Сумму документа", "Сведения о контрагенте по документу" и "Информацию о представленном документе" (включая повторение "DocumentId"). |
|
Какой HTTP код должен вернуть сервис НП, при отправке ответа с типовым элементом Status, который имеет поле Code со значением: • 411 Структура XML документа не соответствует XSD схеме • 412 Документы по запрашиваемым критериям поиска отсутствуют • 435 Количество документов, соответствующих критериям поиска, превышает установленные ограничения • 500 Непредвиденная ошибка |
|
Как должна реагировать ИС НП при получении запроса, который не соответствует критериям, описанным в Приложениях к регламенту взаимодействия через ИС организации при проведении НМ? Например: 1. При получении запроса с некорректным или пустым значением TicketId 2. При получении запроса, не соответствующего критериям описанным в Приложении к регламенту, но соответствующего xsd схеме сценария. (Длина значения для поля больше, чем указано в Приложении. Но, согласно xsd схеме, данное поле – корректно) |
| В обновленной версии документов будет либо добавлен код ошибки, либо добавлены проверки на длину в XSD схему. |
| Согласно политике информационной безопасности наши организации не могут предоставлять в рамках АИС «Налог-3» документы с грифом «Для служебного пользования (ДСП)». Такие документы будут предоставляться в рамках других средств информационного взаимодействия (ТКС). В таком случае, какой Код причины невозможности представления истребуемых документов нам указывать в соответствующем обязательном к заполнению поле (InabilityCode / «КодПричНеПред»)? |
|
Истребуемые документы (информация), пояснения могут быть представлены в налоговый орган лично или через представителя, переданы в электронной форме по телекоммуникационным каналам связи или через информационные системы организации, к которым предоставлен доступ налоговому органу. Если истребование было направлено через сервисы, не обязательно отвечать через сервисы, допускается использовать другой способ взаимодействия, к примеру ТКС. Соответственно указывать код причины невозможности предоставления документов нет необходимости. |
|
Запросом по сервису 17 налоговый орган направляет в адрес налогоплательщика два файла: - XML документ, содержащий результат обработки ответа на требование; - открепленную электронную подпись XML документа, содержащего результат обработки ответа на требование. В документации сервиса №17 предусмотрено 12 проверок электронной подписи (коды проверок 422-432). НП возвращает ответ на запрос по сервису 17 в виде типовой структуры ServiceResponse с указанием кода ответа в элементе Status (Статус обработки запроса) Среди прочих предусмотрен код ответа: "431 Неправильное указание сведений о подписанте в ЭП «Имя_ЭП». Несоответствие ФИО из элемента Signer\FullName в запросе, ФИО из сертификата налогоплательщика." При этом в запросе по сервису 17 нет элемента Signer\FullName. В связи с этим, подскажите, пожалуйста, где взять информацию о "ФИО из сертификата" для осуществления проверки 431? |
|
В описании составного элемента ResponseDocumentInfo для элементов DocumentId и FilePath прописан признак обязательности "О". Иными словами, может быть приложен только один файл запрошенного документа. Приказом ФНС России от 19.12.2023 N ЕД-7-26/970@ утверждены отдельные "описания файла обмена счета-фактуры (информации продавца)" и "файла обмена информации покупателя". Разъясните, пожалуйста, порядок действий при подготовке ответа на требование в соответствии с описанием сервиса №16, в ситуации, когда ФНС запрашивает универсальный передаточный документ, включающий счет-фактуру и универсальный передаточный документ в электронной форме, состоящие из двух xml-файлов: "информация продавца" и "информация покупателя". |
| Элемент ResponseDocumentInfo входит в ResponseInfo, который является множественным. Соответственно, если надо приложить несколько документов к одному пункту истребования, то используется множественность ResponseInfo |
|
Просьба указать, какой из приведенных ниже вариантов заполнения поля ""Наименование и реквизиты документа, подтверждающего полномочия представителя организации (НаимДоК)"" верен для сценария № 3 (Файловый обмен): - Полное наименование XML-файла доверенности с расширением - Идентификационный номер доверенности (GUID) |
|
Можно просто текстом написать номер доверенности и дата выдачи. В 3 сценарии можно использовать только ИСОП, информация об этом указана в таблице «ТИПЫ ДОКУМЕНТОВ, входящих в состав транспортного контейнера» - Идентификационный номер доверенности (GUID) |